Alexander,did you even consider that I might need to convert a date to epoch in a python script? :)

it seems like an easy quest, ain't it? well, it took me far too long to get it done, so let just write it down, so that maybe I won't forget in 2 seconds:

>>> import time
>>> str = '2009-03-04'
>>> format = '%Y-%m-%d'
>>> time.mktime(time.strptime(str, format))
1236121200.0
>>> int(_)
1236121200

It's been two weeks since our "family" has a new element: an african hedgehog. Her name is Shani, that means wonder in swahili.



she is so cute, isn't she?

Since (already) several weeks, bts-link has a new home: busoni.debian.org! That's one of the machines where BTS is running, and it helps to let bts-link complete its job in about 30 mins each time. Thanks goes to Don Armstrong and Peter Palfrader for their support in the migration (from merkel).

Thanks to a colleague, we hereby present the multi-strace:

Some time ago, I asked what are the common solutions for services remote logging. It was suggested scribe, an application log server developed at Facebook and later released as an open source project, and we finally managed to get this ready for Debian squeeze.

It was for a very long time (I think back from PyconIT 2) that I wanted to contribute to python. About a month and a half ago I started reading all the documentation I could about development processes & workflows, mercurial stuff (I don't have commit right, so I prefer working on a DVCS than on SVN), bugs management and so.

Since it took me some time to find this solution, I think it might be worth to share it.

$ curl -H "Host: domain" http://ip_address/path/to/the/page.html

import httplib
conn = httplib.HTTPConnection("ip_address")
conn.putrequest("GET", "/", skip_host=True)
conn.putheader("Host", "domain.ext")
conn.endheaders()
res = conn.getresponse()
print res.read()

As some of you may (or more certainly may not) have noticed reading the Debian Project News, I recently became a Debian maintainer. A hugh thanks to Sandro Tosi (morph) and Piotr O arowski (piotr) for their careful reviews of my work. And thanks to Raphael Hertzog (buxy) to pull the trigger for the beginning of my involvment in Debian. I can t wait to attend Debconf 2010. See you there ! Follow me on Identi.ca: http://identi.ca/carlchenet

oh my...

well, the actual select (against UDD) would be

udd=> select source, all_bugs from bugs_count where source = 'reportbug';
source     all_bugs
----------+----------
reportbug         91

but the result is the same: less than 100 bugs against reportbug! Yay!

As you can see from the bugs graph, the Christmas and Easter holidays helped quite a lot to squash those bugs. When I first step into the reportbug world, the bugs count was around 250, and I first imagined in my mind to brake the 200 barrier, than the 150 and finally the less-than-100 one: while the first 2 limits where the hardest one (new to the codebase, other interest) the last one is the one I'm most proud of.

• use SOAP to query the BTS (no comment here please...)
• use the new.822 to query NEW or incoming and all other sub-queues
• a proper unittest (and I hope the talk @ PyCon Italia will help on this) and check suite
• code refactoring and clean-up of the several dead-branches laying in it
• several other smaller things but still interesting

They seem quite nice-to-have stuff but recently I've tried to concentrate on reply fast to new report, fix as many reported crashes as possible and implement some of the long-awaited features.

Additionally, sometimes "No, sorry" is the proper reply to a bug and then it can be closed: it's hypocrite to keep bugs opened while internally you think it's a wontfix but you're not closing them because of a fear of possibly upset the reporters.

There will be more in the future, that's for sure, but I think this is the reportbug we'll see in squeeze, modulo some new crashes or very interesting feature we want it, so expect minor releases from now until squeeze+1

Yep, I'll be there this year too (sadly I can't say it's my fourth time, since I missed Pycon1).

I'm not that excited about the proposed talks, hey we don't need that much of Django :) I hope the invited speakers will surprise me, I'm confident the organization will do that.

See ya there!

I just discovered nagstamon and all the team fallen in love with it!

I tried to use Nagios Checker, the Firefox plugin to notify of any Nagios alert, but that doesn't play nicely with several opened windows (alerts are multiplied for the number of windows, since it seems everyone does the checks, not just one) and it tends to slow down Firefox, that's already quite slow per se :)

The upstream author provides a Debian package, so promptly I wrote to him asking if he can consider maintain the package in Debian, with me as mentor/co-maintainer and so (it's in Python so I can that :) ); let's see how it goes.

Give it a try, it's really simple and awesome!

Inspired by S. Lott and his blog post (and by the pure genius that xkcd is giving us these days, today included) I gave a look to Project Euler problem 14, that's about the Collatz conjecture.

The straightforward recursive solution:

def collatz(n):
 if n == 1:
     return 1
 if n % 2 == 0:
    return 1 + collatz(n/2)
 else:
    return 1 + collatz(3*n + 1)

very rapidly converges to... an error:

RuntimeError: maximum recursion depth exceeded

So I've recoded it a bit using a cache dictionary to store all the intermediate values in it:

cache =  1: 1 

def collatz(n, res):
 nn = n

 while True:
     if n in cache:
         if nn != n:
             cache[nn] = cache[n]
         return cache[nn]

     if n % 2 == 0:
         cache[n] = 1 + collatz(n/2, cache)
     else:
         cache[n] = 1 + collatz(3*n + 1, cache)

Now loping for all the numbers lower than 1 million we find the solution to the problem: the number with the longest path is 837799 with a path length of 524. The code runs in about 4secs.

Since I got that cache dict around to play with, I graphed with Matplotlib (strange, ha ;) ) the frequencies of each path length:
There are few short paths, several long paths but rare to occur, and most of the paths have length between 100 and 200 (more or less).

UPDATE: I've removed length variable, not needed (left from a previous version of the code) and fixed the path length for 837799, wrongly reported.

Following up my post about using google-code-prettify to syntax highlight code on Blogger, I want to share what I did to tune it for a dark theme.

Big warning: I'm completely ignorant of any web development, html/css/js are kinda arab (no offense intended) for me, so I'm quite sure there are more elegant solutions to this, but at least it works, and seems to have broken nothing :)

So, the default CSS has some bad values for tokens colors, in particular for the keywords and tags (that are in dark blue) and for the plain text (that is in black, so completely hidden).

What I did was to simply override those values, using this table as reference; so now the code to add to Blogger "Minima Black" template (the one I'm using) is:

<link href='http://google-code-prettify.googlecode.com/svn/trunk/src/prettify.css'
    rel='stylesheet' type='text/css'/>
<style type='text/css'>
.pln   color: #C0C0C0;  
.kwd   color: #4169E1;  
.tag   color: #4169E1;  
</style>
<script src='http://google-code-prettify.googlecode.com/svn/trunk/src/prettify.js'
     type='text/javascript'>  </script>

Blogger has no feature to highlight code syntax in blog posts. But google-code-prettify comes to rescue.

The information in their README are quite generic, and treat the situation where you're directly managing the website files, which is not the case for Blogger.

Luka Marinko wrote a very nice blog post describing how to use google-code-prettify on Blogger; I'm going to follow his advices right away!

We often see the opposite, convert a SVN repository into a Git one and try the breeze of a DVCS, but what if you want to convert a Git repo into a SVN one?

The process is not easy (and you need a "straight" Git repo: no merge, too complex branches and so), and the result is quite raw, but you're still able to convert the main part into SVN. Here are the steps:

1. create an empty SVN repository: svn mkdir svn://path/to/repo/project/ trunk,branches,tags
2. clone it in a Git repo: git svn clone svn://path/to/repo/project --stdlayout . This will create a project directory, empty except for the .git information directory; master is the default Git branch created by git-svn that maps SVN trunk.
   
3. add the original Git repo as a remote: git remote add origin git://uri/to/git/repo/project.git
4. fetch from it: git fetch origin
5. create a local branch for the remote master: git checkout -b old_master origin/master . Note that master branch is already present, so we define another one.
6. being on old_master we rebase this branch onto master: git rebase --onto master --root . Doing this, we have "moved" all our commits from old_master to master
7. and push all the commits into the SVN repo: git svn dcommit

It's not that elegant, but it gets it done. I'd like to know if someone is aware of a better method, also to import tags and branches, that this process doesn't do.

After a long time of no Italy mirror, now PHP.net has enabled it.php.net, kindly sponsored by Register.it.

Why am I happy? Because I did it! :)

That is the message you'll receive when trying to open a RRD database created on a 32bit machine from a 64bit one (it's also true the reverse). It's due to the fact that RRD is an architecture-dependent file format: endianess and integer bits length matter.

That's quite boring, given it's quite common to let each machine generate its own RRDs and graph them from a central place, and the more machines you have, the more chances of the above problem.

So, for another example, if you migrate one machine from 32 to 64 bits, you'll have to:

• dump all the RRD databases from the 32 machine
• restore all the RRD databases on the 64 machine

as described here. And when you have +4GB of RRDs it's not so painless.

So, can we haz an architecture independed RRD file format? Pretty please?

It was planned for 1.4, and now that 1.4 is release it's planned for 1.5. Let's hope it comes soon, it would be really nice! :)